The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, the approaches described in this section may not be prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Many network devices, such as routers, gateways and hubs, have grown significantly in complexity in recent years. For example, some routers now include sophisticated multi-processor computing platforms and support a wide variety of components. Example components include, without limitation, interior and exterior routing protocols, such as open shortest path first (OSPF) and border gateway protocol (BGP), respectively, access control lists (ACLs), inventory and resource reservation setup protocol (rsvp). One of the issues with these sophisticated network devices is that different components supported by the network devices have their own application program interfaces (APIs) and data models. Thus, each component has its own command line interface (CLI) that is used to configure the component. This situation typically occurs when components are separately developed and maintained by different design teams and vendors, who use their own APIs and data models for their respective components.
The use of different APIs and data models across components within network devices increases the cost of developing and maintaining network devices since each component has its own API and data model that are not easily shared or re-used across components. This situation also increases the time and expense to develop and maintain management applications because the management applications must support all of the different APIs and data models for the components supported by the network devices. Each change in a component API or data model necessitates a re-building of management applications that manage the changed component.
Manually creating and editing network device configuration data is tedious and prone to errors, particularly for network devices that use large amounts of configuration data. The file containing all of the configuration data for the network device must be downloaded and then manually edited. There are also situations where it is desirable to reuse configuration data across multiple network devices, for example when a large number of identical network devices are deployed. Using conventional editing tools to create multiple copies of configuration data and then to customize the configuration data for particular network devices is also tedious and prone to errors.
Based on the foregoing, there is a need for an approach for developing APIs for network devices that does not suffer from limitations of prior approaches. There is a particular need for an approach for simplifying the development of APIs for network devices. There is a further need for an approach for simplifying the development and maintenance of APIs for network device management applications.